Opportunistic block transmission with time constraints

ABSTRACT

A technique for determining a data window size allows a set of predicted blocks to be transmitted along with requested blocks. A stream enabled application executing in a virtual execution environment may use the blocks when needed.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. Ser. No.13/962,554, filed Aug. 8, 2013, entitled “OPPORTUNISTIC BLOCKTRANSMISSION WITH TIME CONSTRAINTS;” which is a continuation of U.S.Ser. No. 13/234,950 filed Sep. 16, 2011, entitled “OPPORTUNISTIC BLOCKTRANSMISSION WITH TIME CONSTRAINTS,” now U.S. Pat. No. 8,527,706; whichclaims priority to U.S. Ser. No. 12/062,789, filed Apr. 4, 2008 entitled“OPPORTUNISTIC BLOCK TRANSMISSION WITH TIME CONSTRAINTS,” now U.S. Pat.No. 8,024,523; which claims priority to U.S. Ser. No. 60/986,261 filedNov. 7, 2007 entitled “OPPORTUNISTIC BLOCK TRANSMISSION WITH TIMECONSTRAINTS;” all of which are incorporated herein by reference. Thisapplication is also a continuation-in-part of U.S. Ser. No. 11/388,381filed Mar. 23, 2006 entitled “SYSTEM AND METHOD FOR TRACKING CHANGES TOFILES IN STREAMING APPLICATIONS;” which claims priority to U.S. Ser. No.60/664,765 filed on Mar. 23, 2005 entitled “SYSTEM AND METHOD FORTRACKING CHANGES TO FILES IN STREAMING APPLICATIONS;” all of which areincorporated herein by reference.

BACKGROUND

In requesting and receiving blocks of a stream enabled application, someblocks may be predicted as needed following other blocks. When blocksare predicted, there may be uncertainty as to how many predicted blocksto transmit. This may relate to an amount of data to be transmitted. Iftoo many blocks are sent then a delay perceived by a user is increased,and/or network bandwidth is wasted, which may be expensive to astreaming service provider. If too few blocks are sent then bandwidth ofa network connection may be underutilized. If a system refrains fromtransmitting blocks until a user actually requests them then the systemmust transmit the requested blocks while the user waits, expending theuser's valuable time. In many cases users may desire to eliminate suchwaiting time.

The foregoing examples of the related art and limitations relatedtherewith are intended to be illustrative and not exclusive. Otherlimitations of the related art will become apparent to those of skill inthe art upon a reading of the specification and a study of the drawings.

SUMMARY

The following embodiments and aspects thereof are described andillustrated in conjunction with systems, tools, and methods that aremeant to be exemplary and illustrative, not limiting in scope. Invarious embodiments, one or more of the above described problems havebeen reduced or eliminated, while other embodiments are directed toother improvements.

A technique for determining a data window size allows a set of predictedblocks to be transmitted using surplus bandwidth. Advantageously,predicted blocks are transmitted to a streaming playback device beforethe device needs the blocks. A stream enabled application executing in avirtual execution environment may use the blocks when needed withouthaving to wait for their transmission, limiting user delays.

A system based on the technique may include a streaming playback deviceand a streaming server. The streaming server may provide the streamingplayback device blocks that it will need prior to the blocks actuallybeing requested. The streaming playback device may cache necessaryblocks and then use them when needed. A caching system may request onlythose blocks that are not found in cache when requests for blocksinclude some but not all of the blocks in the cache.

BRIEF DESCRIPTION

FIG. 1 depicts a diagram of an example of a system for streamingsoftware.

FIG. 2 depicts a diagram of an example of a system for efficientlytransmitting blocks.

FIG. 3 depicts a flowchart of an example of a method for efficientlytransmitting blocks.

FIG. 4 depicts a diagram of an example of a streaming playback devicereceiving blocks.

FIG. 5 depicts a flowchart of an example of a method for receivingblocks.

FIG. 6 depicts a diagram of an example of a streaming servertransmitting blocks.

FIG. 7 depicts a flowchart of an example of a method for transmittingblocks.

FIG. 8 depicts a diagram of an example of a logical expression of ablock probability table and a diagram of an example of partially filledresponse buffer.

FIG. 9 depicts a diagram of an example of a device for streamingsoftware.

DETAILED DESCRIPTION

In the following description, several specific details are presented toprovide a thorough understanding. One skilled in the relevant art willrecognize, however, that the concepts and techniques disclosed hereincan be practiced without one or more of the specific details, or incombination with other components, etc. In other instances, well-knownimplementations or operations are not shown or described in detail toavoid obscuring aspects of various examples disclosed herein.

FIG. 1 depicts a diagram 100 of an example of a system for streamingsoftware. FIG. 1 includes software provider 102, stream enabler 104, andopportunistic streaming software system 106.

In the example of FIG. 1, software provider 102 supplies a softwareapplication. The software application may be provided as deliverablessuch as data, executable code, and libraries. The application may beprovided by way of CD-ROM, DVD-ROM, download over a network, from aninput/output (I/O) device, or via any known or convenient mechanism.

Resources, e.g. data, executable code, may be included in thedeliverables supplied by the software provider 102. An applicationexecuting in a virtual execution environment may request resources, andit may be necessary to transmit blocks including resources to astreaming playback device for satisfaction of the resource request. Auser may be required to wait while blocks including resources aretransmitted to a streaming playback device.

The software application may have an interactive threshold. Theinteractive threshold may be an amount of time that a user is willing towait for a system to access resources. In a non-limiting example, theinteractivity threshold may be approximately 1/10 of a second because a1/10 of a second delay is noticeable to a human being, and delays ofgreater than 1/10 of a second may decrease user satisfaction with thesoftware. The interactivity threshold may be supplied by the softwareprovider 102, may be determined through trial and error, may bedetermined by systematically executing the software application manytimes and averaging user responses, may be set to a default value (e.g.1/10 of a second) or may be acquired by any method known or convenient.

In the example of FIG. 1, stream enabler 104 prepares the non-streamenabled software application provided by software provided 102 to bestreamed. The stream enabler 104 breaks the non-stream enabled softwareapplication into blocks of an optimal block size. The optimal block sizemay be small so as to allow for aggregation of blocks with finegranularity. The optimal block size may be narrowed to a range, e.g. 512bytes-32k bytes. In some cases the optimal block size may be larger orsmaller than the specified range and may be any size known orconvenient. A deliverable is broken up into many pieces. Each of thepieces may be of the optimal block size, or the pieces may have avariable block size, all of which are the optimal block size or smaller.In some cases, it may even be desirable to increase block size togreater than the optimal block size. In a non-limiting example, theoptimal block size is set to 4 kb and the non-stream enabled softwareapplication is broken up into blocks of a stream-enabled applicationeach up to 4 kb in size, most being of 4 kb. An optimal size of 4k mayhave certain advantages because that is also the page size of manycomputer systems. This can improve memory allocation efficiency, improvesimplicity, and/or have other advantages.

In the example of FIG. 1, opportunistic streaming software system 106may include a streaming software server and a streaming softwareplayback device. A server may be either hardware or software or may be acombination of both hardware software, and firmware. The server mayinclude blocks of the stream-enabled application. The server may becoupled to the streaming software playback device via a network. Thenetwork may have throughput and latency characteristics. The throughputand latency characteristics may be dynamically changing.

Alternatively, in lieu of or in addition to a server, an I/O device thatincludes at last some blocks of the stream enabled application could beused. In this case, the I/O interface may have relevant throughput andlatency characteristics.

FIG. 2 depicts a diagram 200 of an example of a system foropportunistically transmitting blocks. FIG. 2 includes deliverables 202,stream enabler 204, and streaming software system 205.

In the example of FIG. 2, deliverables 202 may be deliverables of anon-stream enabled software application. The deliverables 202 may be thedeliverables as discussed in reference to FIG. 1.

In the example of FIG. 2, stream enabler 204 may be hardware, software,or a combination of hardware and software. The stream enabler may becapable of taking deliverables of a non-stream enabled softwareapplication and breaking the deliverables up into blocks as discussed inreference to FIG. 1.

In the example of FIG. 2, streaming software system 205 includesstreaming software playback device 206, and streaming server 208. In theexample of FIG. 2, streaming playback device 205 includes network dataengine 210, block granularity caching engine 212, and virtualenvironment 208.

In the example of FIG. 2, the block granularity caching engine 212receives requested blocks as well as predictively streamed blocks fromstreaming server 208. Predictively streamed blocks may be blocks thatwere not requested, but were instead predicted to be needed by a streamenabled application executing in the virtual environment 224.Predictively streamed blocks may be stored in a local cache untilneeded. When predictively streamed blocks are needed resources includedin the predictively streamed blocks may be accessed without requestingthe blocks from streaming server 208.

In the example of FIG. 2, network data engine 210 may transmit andreceive information associated with network latency and throughput tostreaming server 208. It may be necessary for the network data engine210 to receive a packet of information that includes a header having atimestamp, but no data. As will be discussed in reference to FIG. 8,packets may be transmitted and received in order to determine and updatenetwork latency information. Similarly the network data engine 210 maytransmit data to the streaming server 208 to determine throughput.

In the example of FIG. 2, the virtual environment 224 may allow astream-enabled application to execute. The virtualized executionenvironment 224 is a virtualized operating system enabling a streamedapplication to execute on a streaming playback device. A virtualizedexecution environment is discussed in U.S. patent application Ser. No.09/098,095 entitled “METHOD AND APPARATUS TO ALLOW REMOTELY LOCATEDCOMPUTER PROGRAMS AND/OR DATA TO BE ACCESSED ON A LOCAL COMPUTER IN ASECURE, TIME-LIMITED MANNER, WITH PERSISTENT CACHING,” which isincorporated by reference.

In the example of FIG. 2, streaming server 208 includes blocks 230,predictive block aggregator 232, and data window engine 234.

In the example of FIG. 2, the blocks 230 are blocks of a stream-enabledapplication. Blocks 230 may be included in a local storage, a database,or may be included in a non-local storage or a non-local database. Adatabase may be a database, may be a file, or may be any known orconvenient manner of storing data.

In the example of FIG. 2, the predictive block aggregator 232 mayprioritize a number of blocks in order of likelihood of use by thestreaming playback device 206. The predictive block aggregator 232 mayadd a number of blocks to a buffer in order of priority. The priority ofthe blocks may be determined as discussed in reference to FIG. 7A-B.Blocks may be added to the buffer until the buffer has reached a datawindow size.

In the example of FIG. 2, the data window engine 234 sets a data windowsize by considering the interactivity threshold of the stream-enabledapplication, the network latency, and the network throughput. Networklatency and network throughput information may be considered on acontinuously updated basis, may be infrequently updated, may be set onlyonce, or may be disregarded. The interactivity threshold may be used inreference to the latency and throughput, or may be used independent ofthat information. The data window size may be used to limit the size ofthe buffer filled with predictively streamed blocks. In a non-limitingexample, the predictively streamed blocks are limited to 10k and blocksare set to 512 bytes. 20 predicted blocks are placed in the buffer, andthe blocks are transmitted.

In the example of FIG. 2, in operation, the deliverables 202 arereceived by the stream enabler 204 and broken up into blocks andprovided to streaming server 208 and stored in blocks 230. The networkdata engine 210 sends a request for a block to the streaming server 208and the data window engine 234 calculates a data window. The predictiveblock aggregator 232 prioritizes the blocks 230 and places a number ofthe blocks 230 into a buffer up to the data window size set by the datawindow engine 234. The blocks in the buffer are transmitted to thestreaming playback device 206 as predictively streamed blocks. The blockgranularity caching engine 212 stores the predictively streamed blocksin to a local cache. An application executing in the virtual environment224 requests a resource, and the resource is at least partiallysatisfied from the blocks in the predictively streamed blocks in thecache.

FIG. 3 depicts a flowchart 300 of an example of a method foropportunistically transmitting blocks. The method is organized as asequence of modules in the flowchart 300. However, it should beunderstood that these and modules associated with other methodsdescribed herein may be reordered for parallel execution or intodifferent sequences of modules.

In the example of FIG. 3, the flowchart 300 starts at module 302 withexecuting a process associated with a stream-enabled application thatprovides a first request for resources. The resource may be needed forexecution of a stream enabled application within a virtualized executionenvironment. The resources may be included in blocks of a stream enabledapplication stored locally or remotely on a streaming system.

In the example of FIG. 3, the flowchart 300 continues to module 304 withreceiving, within a data window, one or more blocks including resourcesused to satisfy the first request for resources as well as one or morepredictively streamed blocks. The data window may limit the number ofpredictively streamed blocks that may be transmitted. The resources inthe one or more blocks may be used to satisfy the first request forresources. The predictively streamed blocks may be associated with aprobability of being requested by the stream enabled application in thefuture.

In the example of FIG. 3, the flowchart 300 continues to module 306 withstoring one or more predictively streamed blocks in a cache. The blocksmay be blocks that include resources that have a high likelihood ofbeing used by the stream enabled application for a subsequent requestfor resources. A streaming system may predictively stream the blocks inadvance of the stream enabled application requesting resources includedin the blocks.

In the example of FIG. 3, the flowchart 300 continues to module 308 withproviding a second request for resources. The second request forresources may be associated with one or more blocks that werepredictively streamed in advance of the second request for resources.

In the example of FIG. 3, the flowchart 300 continues to module 310 withchecking the cache to find the one or more predictively streamed blocksto satisfy the block request. If blocks including the resource werepredictively streamed in advance, the resource may be found in blocks inthe cache. However, blocks including the resource may not have beenpredictively streamed, or may have gone unused for a sufficient amountof time for the blocks to have been replaced with other blocks that havebeen more recently predictively streamed.

In the example of FIG. 3, the flowchart 300 continues to module 312 withat least partially satisfying the request for the resource using the oneor more predictively streamed blocks in the cache. In some cases theresource may be spread across more than one block. One or more blocksincluding the resource may not be in the cache when needed. Blocks notfound in the cache must be requested so that all blocks necessary areavailable so that the resource may be provided. In the case that theresource is entirely included in blocks in the cache, the entireresource is produced from the blocks in the cache, and the resourcerequest is satisfied. Having satisfied the request for the resource, theflowchart terminates.

FIG. 4 depicts a diagram 400 of an example of a streaming playbackdevice receiving blocks. FIG. 4 includes streaming playback device 402,streaming system 412, and blocks 414.

In the example of FIG. 4, the streaming playback device 402 includesvirtual environment 404, cache 406, block granularity caching engine408, and interface 410.

In the example of FIG. 4, the virtual environment 404 may be avirtualized operating system enabling a streamed application to executeon a computing device as discussed in reference to FIG. 2.

In the example of FIG. 4, the cache 406 may store one or more blocks,the blocks including one or more resources. Blocks may be stored in alast-in-first-out (LIFO), associative cache, or any caching system knownor convenient. Blocks that are used may be maintained in the cache 406while blocks that are not used may be replaced by more recentpredictively streamed blocks.

In the example of FIG. 4, the block granularity caching engine 408 mayreceive predicted blocks as they are transmitted to the streamingplayback device 402. The blocks may be stored in the cache 406 by theblock granularity caching engine 408. The block granularity cachingengine 408 may intercept block requests from the virtual executionenvironment 404, and inspect the cache 406 to determine if some, all ornone of the blocks are found in the cache 406. If some of the blocks arefound in the cache 406, then the block granularity caching engine 408may create a modified block request including a request for blocks thatwere requested by the virtual execution environment 404, but not foundin the cache 406. If none of the blocks are found in the cache 406, theblock granularity caching engine 408 may create a block request for allblocks requested by the virtual execution environment 404. If all of theblocks are found in the cache, the block granularity caching engine 408may provide all blocks requested directly to the virtual executionenvironment 404, and may refrain from transmitting any request forblocks.

In the example of FIG. 4, the interface 410 may provide block requeststo the streaming system 412. The interface 410 may receive blocks fromthe streaming system 412 and provide the blocks to the block granularitycaching engine 408. An interface should be afforded a broad enoughinterpretation to include a bus within a single computing system, awireless or wired connection between computing systems, or any known orconvenient manner of transmitting blocks of a stream enabledapplication. The interface could be an input/output device, for readinga fixed media such as a CD-ROM, DVD-ROM, or other computer readablemedia.

In the example of FIG. 4, the streaming system 412 may be a separatecomputing device from streaming playback device 402, may be a fixedmedia from which a stream-enabled application is read, or may be anysource of a stream enabled application. The streaming system 412 mayinclude the blocks 414, or may be coupled to a computing deviceincluding the blocks 414. In the case of a fixed media, the streamingplayback device 402 reads blocks from the input output device such as aCD-ROM, DVD-ROM, or other known or convenient computer readable medium.

In the example of FIG. 4, the blocks 414 may include blocks of a streamenabled application. Blocks 414 may be a file, a group of files, adatabase, a data store, or any manner known or convenient of storing astream enabled application.

In the example of FIG. 4, in operation, a stream enabled applicationexecuting within the virtual execution environment 404 may request, forexample, a resource in terms of a file offset and length. The virtualexecution environment 404 may interpret the resource request as block 7.The block granularity caching engine 408 may then inspect the cache 406to determine whether the requested block 7 is in the cache or not. Ifthe requested block 7 is in the cache, then the block granularitycaching engine 408 may provide the requested block to the virtualexecution environment 404. If the requested block is not in the cache406 then the block granularity caching engine 408 may then request theblock 7 from the streaming system 412. The streaming system 412 mayreply with block 7 and perhaps, by way of example, but not limitation,additional predictive blocks 7, 8, & 9. The additional blocks 8 and 9may have a high likelihood of being needed after block 7 is requested.The block granularity caching engine 408 may provide the requested block7 to the virtual execution environment 404, and may cache thepredictively streamed blocks 8 and 9, as well as the requested block 7.The resources in the requested block 7 may be provided by the virtualexecution environment 404 to the stream enabled application in terms ofa file, offset and length.

FIG. 5 depicts a flowchart 500 of an example of a method for receivingblocks. The method is organized as a sequence of modules in theflowchart 500. However, it should be understood that these and modulesassociated with other methods described herein may be reordered forparallel execution or into different sequences of modules.

In the example of FIG. 5, the flowchart 500 starts at module 502 withrequesting a resource of a stream enabled application. A stream enabledapplication may request the resource in terms of a file, offset andlength.

In the example of FIG. 5, the flowchart 500 continues to module 504 withtranslating the request for the resource into a block ID of a blockincluding the resource. The resource may be included in a block, or maybe spread across one or more blocks. The translation may thus include aplurality of blocks or merely a single block.

In the example of FIG. 5, the flowchart 500 continues to module 506 withinspecting a cache for the block. It may be that the block has beenpreviously received, and is stored in cache. The block may have beenpreviously requested, or may have been predictively streamed because itwas likely that the resource included in the block would be requested.If a block is present, then the block is locked, or otherwise preventedfrom being deleted until the resource request is responded to. A lockedblock may be unlocked after the resource request is responded to.

In the example of FIG. 5, the flowchart 500 continues to module 508 withtransmitting a request for the block. If the block was not found in thecache it may be necessary to request the block.

In the example of FIG. 5, the flowchart 500 continues to module 510 withreceiving the block as well as additional predictively streamed blocks.In the case that one or more blocks are likely to be requested after theblock, predictively streamed blocks may be transmitted along with theblock, taking into consideration, a window for transmission based on theamount of time that a user may be willing to wait as well as the amountof data that may be transmitted in the time.

In the example of FIG. 5, the flowchart 500 continues to module 512 withcaching the additional predictively streamed blocks. These additionalpredictively streamed blocks may be stored for future use. Blocks in thecache that are not needed may be replaced by predictively streamedblocks. Any locked blocks may not be replaced by additional predictivelystreamed blocks. Having cached the additional predictively streamedblocks, the flowchart terminates.

FIG. 6 depicts a diagram 600 of an example of a streaming servertransmitting blocks. FIG. 6 includes streaming server 602, and streamingplayback device 616.

In the example of FIG. 6, streaming server 602 includes predictor 604,blocks 608, predicted block aggregation engine 612, output buffer 610,and interface 614.

In the example of FIG. 6, the predictor 604 determines a likelihood ofblocks being requested. The predictor creates probability data. Thepredictor is discussed in more depth in U.S. patent application Ser. No.10/988,014 entitled “SYSTEM AND METHOD FOR PREDICTIVE STREAMING” byJeffrey de Vries, incorporated herein by reference.

In the example of FIG. 6, the probability data 606 includesprobabilities of blocks being requested after blocks that have alreadybeen requested, such as is discussed in reference to FIG. 7. Theprobability data may be expressed as a logical block probability table,as a data store of probabilities, or in any manner known or convenient.

In the example of FIG. 6, the output buffer 610 may be any computerreadable medium capable of storing data. The output buffer 610 may bevolatile, or non-volatile. In a non-limiting example, the output buffermay include random access memory. The output buffer 610 may store blocksprior to transmission.

In the example of FIG. 6, the predicted block aggregation engine 612includes functionality to fill an output buffer with blocks from blocks608 based on block probability data 606. The predictive blockaggregation engine 612 may add blocks to the output buffer up to a limitset by a data window size as discussed in reference to FIG. 7. The datawindow size may be limited by user responsiveness requirements and amaximum throughput between interface 614 and streaming playback device616. An engine normally includes a processor and memory includinginstructions for execution by the processor.

Notably, below, two examples are provided of pseudo code that could beimplemented to fill the output buffer 610 with blocks. However, neitherthe first example, nor the second example are limiting. Any known orconvenient manner of filling the output buffer 610 with blocks may beused.

In a non-limiting example, the predicted block aggregation engine 612may implement a priority queue to fill the output buffer with blocks.Consider a priority queue PQ. PQ contains tuples (pq,bq) each containinga probability (pq) and a block number (bq). The priority queue may beordered by probability. A minimum probability tuple may always sit atthe top of the queue. Initially PQ is empty. Q may be a working queue oftuples (pw,bw) each containing a probability (pw) and a block number(bw). PROB may be an indexed probability table 606 storing a probabilityof needing a predicted block having seen one or more previous blocks.The probability may be set in the range of 0-1. Let N be the max numberof blocks that you can put into the output buffer=data window size/blocksize.

In continuing the non-limiting example, the following pseudo-code couldbe implemented to fill an output buffer with predicted blocks up to amaximum data window:

PUSH (1.0, requested block) onto working queue Q WHILE working queue Qis not empty DO  POP (pw,bw) with probability pw and block number bwfrom working  queue Q  IF (PQ.size = N) (i.e. PQ already has N entries)DO   IF (pw <= PQ.min (i.e. the min probability at the top of the PQ))DO    CONTINUE back at the WHILE (i.e. skip this block)   END IF   IF(PQ already contains an entry for block number bw) DO   IF (theprobability in the entry for block bw in PQ >= pw) DO    CONTINUE backat the WHILE (i.e. keep existing entry)    ELSE     REMOVE the entry forblock bw from PQ    END IF   END IF  END IF  PUSH (pw, bw) onto priorityqueue PQ (updating the min entry as  necessary)  FOR EACH predictedblock bp for which PROB[bw][bp] > 0 DO  PUSH (pw * PROB[bw][bp], bp)onto working queue Q  END FOR LOOP END WHILE LOOP FOR EACH block in thepriority queue DO  go read the block data and put the block number andthe block data into the output buffer END FOR LOOP SEND output buffercontaining requested block + top N-1 blocks based on probability

Notably, one could use as many stages of look ahead as is desirable. Onecould have PROB[seen1][seen2] . . . [seen n] [predicted block]=theprobability of seeing the predicted block give the sequence ofpreviously seen blocks seen 1 . . . seen n. The additional stages oflook ahead may provide better focused predictions of blocks. In anothernon-limiting example, the following pseudo code could be implemented tofill the output buffer with blocks. Q is a working queue of(probability, block number) tuples, sorted by order of decreasingprobability, initially empty. Let probability table be same as discussedabove relative to the first example.

PUSH (1.0, requested block) onto working queue Q WHILE working queue Qis not empty AND output buffer is not full DO  POP (pw,bw) withprobability pw and block number bw from working  queue Q  IF outputbuffer doesn't already contain block bw   ADD block number bw and datafor block bw to output buffer  END IF  FOR EACH predicted block bp forwhich PROB[bw][bp] > 0 DO   IF output buffer doesn't already containblock bp    INSERT (pw * PROB[bw][bp], bp), sorted by decreasingprobability, into working queue Q   END IF  END FOR LOOP END WHILE LOOPSEND output buffer

In the example of FIG. 6, the data window engine 613 sets a data windowsize by considering the interactivity threshold of the stream-enabledapplication, the network latency, and the network throughput. Networklatency and network throughput information may be considered on acontinuously updated basis, may be infrequently updated, may be set onlyonce, or may be disregarded. The interactivity threshold may be used inreference to the latency and throughput, or may be used independent ofthat information. The data window size may be used to limit the size ofthe buffer filled with predictively streamed blocks.

In the example of FIG. 6, the interface 614 may be an interface asdiscussed in reference to FIG. 9. It should be appreciated that theinterface may be interpreted broadly enough to include connectionswithin a single computing system. Additionally, the interface may anymeans of transmitting data, e.g., optical network, ethernet, or anymeans known or convenient.

In the example of FIG. 6, the streaming playback device 616 may includea virtualized environment for a stream enabled application. Streamingplayback device 616 may include a processor, non-volatile memory, and aninterface. The streaming playback device 616 may include a virtualexecution environment executing a stream enabled application thatrequests resources. A resource request may be translated into a blockrequest.

In the example of FIG. 6, in operation, the streaming playback device616 creates a request for a block. The request is provided to streamingserver 602. The predictor 604 predicts a number of blocks that arelikely to be requested after the block and stores the predictions inprobability data 606. Predicted block aggregation engine 612 identifiesthe blocks in probability data 606 that are likely to be requested afterthe block, and adds zero or more blocks from the blocks 608 until theoutput buffer 610 has reached a data window size. Once the output buffer610 has reached the data window size, the output buffer is provided, viathe interface 614, to the streaming playback device 616.

FIG. 7 depicts a flowchart 700 of an example of a method fortransmitting blocks. The method is organized as a sequence of modules inthe flowchart 700. However, it should be understood that these andmodules associated with other methods described herein may be reorderedfor parallel execution or into different sequences of modules.

In the example of FIG. 7, the flowchart 700 starts at module 702 withpredicting one or more blocks that are associated with resources thatwill be requested by a stream-enabled application. As many stages oflook ahead as is desirable may be used to provide predictions of futureblocks. In a non-limiting example, given that the streaming playbackdevice requested block 4, a predictor could predict that the next threeblocks that will be requested by a streaming playback device will be, inorder of probability, 7, 15, and 24.

In the example of FIG. 7, the flowchart 700 continues to module 704 withadding predicted blocks to an output buffer in order of priority untilan output buffer has reached the data window size. The blocks may beadded in priority, by likelihood of being requested, or by any known orconvenient manner. In a non-limiting example, the blocks added may beginwith the block requested followed by the block most likely be requested,until the maximum, e.g., 32K of blocks have been added to the buffer.

In the example of FIG. 7, the flowchart 700 continues to module 706 withtransmitting the blocks in the output buffer. The blocks in the bufferare provided to the streaming software client. Having transmitted theblocks in the output buffer, the flowchart terminates.

FIG. 8 depicts a diagram 800A of an example of a logical expression of ablock probability table and a diagram 800B of an example of partiallyfilled response buffer.

In the example of FIG. 8, the diagram 800A includes probabilities of astreaming playback device requesting blocks. Each row of this tableincludes the probability of each block being needed after this block.Diagonally square (7,7), through square (13,13) include no probabilitiesas such would calculate the probability of a block being requestedimmediately after the block, itself, is requested. In the example ofFIG. 8, for example, the probability of block 11 being requested afterblock 7 is 0.1, or 10%. In a non-limiting example, this might be becauseblock 8 is only used by the streamed application when an error conditionoccurs, and that error condition only occurs about 10% of the time,e.g., a misspelled file name.

In the example of FIG. 8, the diagram 800B includes the partially filledresponse buffer storing a requested block as well as a plurality ofpredicted blocks. It may not be necessary or possible to fill theresponse buffer completely with blocks. In a non-limiting example, ifblock 7 is requested, and no blocks are predicted to follow block 7,then it may not be possible to fill a 10-block-long output bufferbecause there are not enough blocks to send.

In determining a data window size, the following non-limiting examplesan interactive threshold may be calculated, however, any known orconvenient method of calculating a data window size may be used. Thefollowing non-limiting examples are provided for clarity.

In a non-limiting example of a method for calculating a data window sizeMAX WINDOW may be an upper limit of the largest amount of data that theresponse buffer may hold. Throughput may be a value representing theamount of data per unit of time that may be transmitted on a networkconnecting a streaming server with a streaming playback device. The datawindow size may thus be calculated: data window=MIN[MAXIMUM_WINDOW,throughput*interactive threshold].

In a non-limiting example, an interactive threshold is a limit on theamount of time that an individual may be willing to wait for a block. Alatency may be a time delay between deciding to transmit a block andtransmitting the first bit of the block. A throughput may be a valuerepresenting the amount of data per unit of time that may be transmittedon a network connecting a streaming server with a streaming playbackdevice. The data window size may thus be calculated: datawindow=(interactive threshold−round trip latency)*throughput.

In a non-limiting example a MIN_WINDOW_SIZE may be a lower limit of thesmallest amount of data that the response buffer may hold. Aninteractive threshold and a latency may be as described above. The datawindow may be thus calculated data window=MAX [MIN_WINDOW_SIZE,(interactive threshold−(round trip latency))*throughput].

Any manner of determining a latency known or convenient may be used.Latency may be important because an interactive threshold is decreasedby subtracting a latency from the time allowed for the interactivethreshold. Any manner of determining a latency known or convenient maybe used. Latency may be continuously recalculated throughout a streamingsession so as to provide an accurate data window size.

Throughput may be dynamically determined by, at the beginning of thesession, sending test buffers between a server and a client. Thethroughput may be calculated, based on the time required to transmit thebuffers, and the data size of the buffers. The throughput could be runthrough a low pass filter to obtain an average throughput, to get aconstant updated throughput. If something in the network switchesroutes, then we may adapt our window size. Alternatively, any manner ofdetermining a throughput known or convenient may be used.

FIG. 9 depicts a diagram 900 of an example of a device for streamingsoftware. The computing system 900 may be a computing system that can beused as a client computing system, such as a wireless client or aworkstation, or a server computing system. The computing system 900includes a computer 902, and a display device 906. The computer 902includes a processor 908, interface 910, memory 912, display controller914, and non-volatile storage 916. The computer 902 may be coupled to orinclude display device 906.

The computer 902 interfaces to external systems through the interface910, which may include a modem, network interface, CD-ROM drive, DVD-ROMdrive, or any known or convenient interface. An interface may includeone or more input-output devices. Interface 910 may include one or moreinterfaces. An interface may include a device for reading a fixed media.An interface may receive deliverables. An interface may transmit astream-enabled application. It will be appreciated that the interface910 can be considered to be part of the computing system 900 or a partof the computer 902. The interface 910 can be an analog modem, ISDNmodem, cable modem, token ring interface, satellite transmissioninterface (e.g. “direct PC”), or other interface for coupling acomputing system to other computing systems.

The processor 908 may be, for example, a microprocessor such as an IntelPentium microprocessor or Motorola power PC microprocessor. The memory912 is coupled to the processor 908 by a bus 920. The memory 912 can beDynamic Random Access Memory (DRAM) and can also include Static RAM(SRAM). The bus 920 couples the processor 908 to the memory 912, also tothe non-volatile storage 916, and to the display controller 914.

The non-volatile storage 916 is often a magnetic hard disk, an opticaldisk, or another form of storage for large amounts of data. Some of thisdata is often written, by a direct memory access process, into memory912 during execution of software in the computer 902. One of skill inthe art will immediately recognize that the terms “machine-readablemedium” or “computer-readable medium” includes any type of storagedevice that is accessible by the processor 908 and also encompasses acarrier wave that encodes a data signal.

The computing system 900 is one example of many possible computingsystems which have different architectures. For example, personalcomputers based on an Intel microprocessor often have multiple buses,one of which can be an I/O bus for the peripherals and one that directlyconnects the processor 908 and the memory 912 (often referred to as amemory bus). The buses are connected together through bridge componentsthat perform any necessary translation due to differing bus protocols.

Network computers are another type of computing system that can be usedin conjunction with the teachings provided herein. Network computers donot usually include a hard disk or other mass storage, and theexecutable programs are loaded from a network connection into the memory912 for execution by the processor 908. A Web TV system, which is knownin the art, is also considered to be a computing system, but it may lacksome of the features shown in FIG. 9, such as certain input or outputdevices. A typical computing system will usually include at least aprocessor, memory, and a bus coupling the memory to the processor.

In addition, the computing system 900 is controlled by operating systemsoftware which includes a file management system, such as a diskoperating system, which is part of the operating system software. Oneexample of operating system software with its associated file managementsystem software is the family of operating systems known as Windows®from Microsoft Corporation of Redmond, Wash., and their associated filemanagement systems. Another example of operating system software withits associated file management system software is the Linux operatingsystem and its associated file management system. The file managementsystem is typically stored in the non-volatile storage 916 and causesthe processor 908 to execute the various acts required by the operatingsystem to input and output data and to store data in memory, includingstoring files on the non-volatile storage 916.

Some portions of the detailed description are presented in terms ofalgorithms and symbolic representations of operations on data bitswithin a computer memory. These algorithmic descriptions andrepresentations are the means used by those skilled in the dataprocessing arts to most effectively convey the substance of their workto others skilled in the art. An algorithm is here, and generally,conceived to be a self-consistent sequence of operations leading to adesired result. The operations are those requiring physicalmanipulations of physical quantities. Usually, though not necessarily,these quantifies take the form of electrical or magnetic signals capableof being stored, transferred, combined, compared, and otherwisemanipulated. It has proven convenient at times, principally for reasonsof common usage, to refer to these signals as bits, values, elements,symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities. Unlessspecifically stated otherwise as apparent from the following discussion,it is appreciated that throughout the description, discussions utilizingterms such as “processing” or “computing” or “calculating” or“determining” or “displaying” or the like, refer to the action andprocesses of a computing system, or similar electronic computing device,that manipulates and transforms data represented as physical(electronic) quantities within the computing system's registers andmemories into other data similarly represented as physical quantitieswithin the computing system memories or registers or other suchinformation storage, transmission or display devices.

The teachings included herein also relate to an apparatus for performingthe operations herein. This apparatus may be specially constructed forthe required purposes, or it may comprise a general purpose computerselectively activated or reconfigured by a computer program stored inthe computer. Such a computer program may be stored in a computerreadable storage medium, such as, but is not limited to, read-onlymemories (ROMs), random access memories (RAMs), EPROMs, EEPROMs,magnetic or optical cards, any type of disk including floppy disks,optical disks, CD-ROMs, and magnetic-optical disks, or any type of mediasuitable for storing electronic instructions, and each coupled to acomputing system bus.

The algorithms and displays presented herein are not inherently relatedto any particular computer or other apparatus. Various general purposesystems may be used with programs in accordance with the teachingsherein, or it may prove convenient to construct more specializedapparatus to perform the required method steps. The required structurefor a variety of these systems will appear from the description below.In addition, there is no reference to any particular programminglanguage, and various examples may be implemented using a variety ofprogramming languages.

It will be appreciated to those skilled in the art that the precedingexamples and embodiments are exemplary and not limiting in scope. It isintended that all permutations, enhancements, equivalents, andimprovements thereto that are apparent to those skilled in the art upona reading of the specification and a study of the drawings are includedwithin the true spirit and scope of these teachings. It is thereforeintended that the following appended claims include all suchmodifications, permutations, and equivalents as fall within the truespirit and scope of these teachings.

What is claimed is:
 1. A method comprising: beginning execution of astream-enabled application at a streaming playback device; determining afirst resource needed to continue execution of the stream-enabledapplication; determining if the first resource is present in a cache ofthe streaming playback device; if it is determined that a blockincluding the first resource is present in the cache, retrieving theblock including the first resource for use in continued execution of thestream-enabled application; if it is determined that first the resourceis absent from the cache: sending a request for the block including thefirst resource to a streaming server; receiving, from the streamingserver, the block including the first resource and at least onepredicted block used in execution of the stream-enabled application, theat least one predicted block determined based on a probability that theat least one predicted block will be requested in execution of thestream-enabled application, a number of blocks included in the at leastone predicted block based on a data window size; storing the blockincluding the first resource and the at least one predicted block in thecache; using the block including the first resource to continueexecution of the stream-enabled application.
 2. The method of claim 1,wherein the data window size is based on an interactivity threshold. 3.The method of claim 1, wherein the data window size is based on userresponsiveness requirements.
 4. The method of claim 1, wherein the datawindow size is based on network throughput between the streaming serverand the streaming playback device.
 5. The method of claim 1, wherein thedata window size is based on network latency between the streamingserver and the streaming playback device.
 6. The method of claim 1,wherein the at least one predicted block includes a plurality of blocksreceived as part of an output buffer, the plurality of blocks organizedin the output buffer according to the probability that they will berequested.
 7. The method of claim 1, wherein the probability of the atleast one predicted block in being requested is based on whether the atleast one predicted block is requested by the stream-enabled applicationwhen an error condition occurs in executing the stream-enabledapplication at the streaming playback device.
 8. The method of claim 1,wherein the data window size is continuously updated based on at leastone of an interactivity threshold, network throughput between thestreaming server and the streaming playback device, and network latencybetween the streaming server and the streaming playback device.
 9. Themethod of claim 1, further comprising: determining a second resourceneeded to continue execution of the stream-enabled application;determining if the second resource is present in the cache of thestreaming playback device; if it is determined that a block includingthe second resource is present in the cache, retrieving the blockincluding the second resource from the cache for use in continuedexecution of the stream-enabled application.
 10. The method of claim 1,wherein the block including the second resource included in the at leastone predicted block.
 11. A system comprising: a streaming playbackdevice configured to: begin execution of a stream-enabled application;determine a first resource needed to continue execution of thestream-enabled application; a client block granularity engine configuredto: determine if the first resource is present in a cache of thestreaming playback device; retrieve the block including the firstresource for use in continued execution of the stream-enabledapplication, if it is determined that a block including the firstresource is present in the cache; a network data engine configured to:send a request for the block including the first resource to a streamingserver, if it is determined that first the resource is absent from thecache; receive, from the streaming server, the block including the firstresource and at least one predicted block used in execution of thestream-enabled application, the at least one predicted block determinedbased on a probability that the at least one predicted block will berequested in execution of the stream-enabled application, a number ofblocks included in the at least one predicted block based on a datawindow size; the client block granularity engine further configured to,store the block including the first resource and the at least onepredicted block in the cache; the streaming playback device furtherconfigured to use the block including the first resource to continueexecution of the stream-enabled application.
 12. The system of claim 11,wherein the data window size is based on an interactivity threshold. 13.The system of claim 11, wherein the data window size is based on userresponsiveness requirements.
 14. The system of claim 11, wherein thedata window size is based on network throughput between the streamingserver and the streaming playback device.
 15. The system of claim 11,wherein the data window size is based on network latency between thestreaming server and the streaming playback device.
 16. The system ofclaim 11, wherein the at least one predicted block includes a pluralityof blocks received as part of an output buffer, the plurality of blocksorganized in the output buffer according to the probability that theywill be requested.
 17. The system of claim 11, wherein the probabilityof the at least one predicted block in being requested is based onwhether the at least one predicted block is requested by thestream-enabled application when an error condition occurs in executingthe stream-enabled application at the streaming playback device.
 18. Thesystem of claim 11, wherein the data window size is continuously updatedbased on at least one of an interactivity threshold, network throughputbetween the streaming server and the streaming playback device, andnetwork latency between the streaming server and the streaming playbackdevice.
 19. The system of claim 11, wherein: the streaming playbackdevice is further configured to determine a second resource needed tocontinue execution of the stream-enabled application; the client blockgranularity caching engine is further configured to: determine if thesecond resource is present in the cache of the streaming playbackdevice; retrieve the block including the second resource from the cachefor use in continued execution of the stream-enabled application, if itis determined that a block including the second resource is present inthe cache, the block including the second resource included in the atleast one predicted block.
 20. A system comprising: means for beginningexecution of a stream-enabled application at a streaming playbackdevice; means for determining a first resource needed to continueexecution of the stream-enabled application; means for determining ifthe first resource is present in a cache of the streaming playbackdevice; means for retrieving the block including the first resource foruse in continued execution of the stream-enabled application, if it isdetermined that a block including the first resource is present in thecache; means for sending a request for the block including the firstresource to a streaming server, if it is determined that first theresource is absent from the cache; means for receiving, from thestreaming server, the block including the first resource and at leastone predicted block used in execution of the stream-enabled application,the at least one predicted block determined based on a probability thatthe at least one predicted block will be requested in execution of thestream-enabled application, a number of blocks included in the at leastone predicted block based on a data window size; means for storing theblock including the first resource and the at least one predicted blockin the cache, if it is determined that first the resource is absent fromthe cache; means for using the block including the first resource tocontinue execution of the stream-enabled application.